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Background of Invention 

[0002] The present invention relates generally to a method for 
determining insurance status verification on an object of 
value and, more particularly, to a system and method for 



both instantly and automatically verifying the presence or 
absence of insurance coverage without regard to insurer 
or jurisdiction. It is an insurance verification, not an insur- 
ance reporting or tracking system, and because it main- 
tains no personal data of any kind, and can modify no 
record, it can deliver only very limited features regarding 
reporting or tracking. The present invention can however, 
provide absolute assurance of current insurance status at 
all times, provides a unique method of access which re- 
solves all current failures and is non-invasive, providing 
complete privacy for all parties involved. This invention 
further ensures that any check of status, at insurer or 
governmental registration, (including "e-registration"), in- 
spection, or any other location and time when and where a 
jurisdiction or insurer requires such a status check, will 
result in an instant and totally accurate status response. 
[0003] The uninsured status of various objects of value, espe- 
cially vehicles and equipment, continues to create a seri- 
ous financial and, in many cases a safety burden on Soci- 
ety. Insurance rates continue to increase, due in part, to 
the continued existence of large numbers of uninsured 
vehicles and numerous other items which otherwise ap- 
pear to be insured. In regards to vehicles alone, the fail- 



ures of current systems, according to FBI (Federal Bureau 
of Investigation) statistics, cost the owners of motor vehi- 
cles, and their insurers over $9B (nine billion dollars) in 
paid claims on motor vehicles alone, and another esti- 
mated $12-13B (twelve to thirteen billion dollars) in re- 
lated damages for vehicle theft and theft-related fraud 
annually, and many insurance analysts claim these esti- 
mates are far too conservative. Also, these numbers do 
not reflect the cost of uninsured motorist coverage which 
adds additional billions. Additionally, there are countless 
deaths each year attributable to drivers who would doubt- 
less have stayed at home or found other means of trans- 
portation if they knew that, in driving and being checked 
in any manner, their uninsured status would have been 
immediately known. Once vehicle coverage is obtained 
and insurance documents are issued, there is little oppor- 
tunity to again verify its existence and/or status. 
[0004] There are many problems with all previous methods of in- 
surance verification. Many insurers allow for insurance 
premiums to be paid in monthly installments. Insurance 
registration documents are issued after the first payment 
indicating that the object of value is insured for a certain 
period of time, generally either six months or a year, but 



if, after the first payment, the policyholder does not make 
any additional premium payments, the insurance coverage 
will no longer exist even though the policyholder's insur- 
ance documents indicate that the object of value is in- 
sured for an additional five or eleven months, etc. Prior to 
the development and implementation of the present in- 
vention, there has been no adequate verification tech- 
nique capable of detecting lapses in insurance coverage. 

[0005] a need has long existed for a universal, centralized sys- 
tem for instant, accurate insurance status verification. 
Records used for such verification continue to be main- 
tained by various unrelated parties and often at disparate, 
off-site locations. Further, all attempts at providing a uni- 
versal site for any jurisdiction, and centralizing such 
records to ensure that all information is current and accu- 
rate, have failed. Attempts to provide safe, non-invasive 
access to various, unrelated parties using a "client-server" 
atmosphere that is telephony or computer-based, have 
also demonstrably failed. 

[0006] There are over 4300, (four thousand, three hundred), sep- 
arate insurers licensed to provide property and casualty 
insurance policies in the United States alone, and it is not 
uncommon for a single State to have over one thousand 



such carriers providing such policies. There is almost an 
equal number of insurers licensed to provide other forms 
of insurance for additional objects of value and individu- 
als. No legislation or regulation that requires current re- 
porting will be acceptable by the insurance industry, (or if 
accepted, not without massive, negative financial impact), 
unless a solution can be provided that requires almost no 
cost or implementation effort, is non-invasive for both in- 
surers and policyholders, provides solutions to internal 
and external fraud concerns, and once in place, requires 
little or no maintenance. All this is provided by the inven- 
tion. 

[0007] one indicator of the failures of current insurer and gov- 
ernment efforts relates specifically to vehicle insurance. It 
is estimated that as much as thirty percent of all VINs, 
(vehicle identification numbers - the primary method of 
determining the identity of a particular vehicle), main- 
tained by State Government DMVs, are incorrect. Since 
1980, this 17-character vehicle identification number 
(VIN) is imprinted on each vehicle. The VIN is coded so 
that the first eleven characters usually represent the fol- 
lowing: country of origin, vehicle type, number of passen- 
gers, restraint system, car manufacturer model identifica- 



tion, vehicle series, body type description, engine size, a 
check digit, model year and manufacturing plant. The last 
six digits are different for each vehicle. Prior to 1980, a 
nine character VIN was used, with different placement, but 
with similar results. It is very difficult to properly read, 
record and maintain records regarding such alphanumeric 
identifiers. Additionally, other methods of identification 
regarding a particular vehicle are also potentially inaccu- 
rate. There are at least three parties creating detailed 
records of each vehicle independently. As discussed, the 
manufacturer stamps a vehicle identification number (VIN) 
on the vehicle which is coded to reveal particular informa- 
tion about the vehicle; and then each individual jurisdic- 
tion (State, District or Province) issues a "new" title num- 
ber each time a vehicle changes owners, (and new regis- 
tration plates and related documents every time insurance 
or ownership changes), and an insurer in the insurance 
industry maintains totally separate and different identi- 
fiers. 

[0008] Current government systems use dissimilar multi-key 
tracking. For example, in dealing with vehicles, The VIN, 
title and the registration license plate must be combined, 
and the three keys "matched" to the owner, and then sent 



to another file or database program to "contextually 
cross-match" the data files to see if there is a match (as 
disclosed in U.S. Patent No. 4,989,144 to Barnett III) and 
then the process must be reversed to all three or four 
"data-tracking keys" to update each file in the disparate 
databases while still maintaining a further "contextually- 
matched" database. Similar methods, (and resultant ineffi- 
ciencies) are common in the maintenance of land and title 
deeds and records of all kinds regarding taxable objects 
of value. The present invention corrects these failures by 
providing a unique identifier to the object of value, and 
which circumvents the need for accurate records else- 
where. Even if other identifiers are incorrect, the "UC", 
(Unique Code - a unique, numeric-only identifier, issued 
and used only once), provides access to accurate status 
data. 

[0009] This same concern is seen in numerous additional 

patents, (as disclosed in U.S. Patent No. 6,233,563 to Jef- 
ferson, as disclosed in U.S. Patent No. 6,076,064 to Rose, 
Jr., and as disclosed in U.S. Patent No. 6,437,690 to 
Okezie). Almost all States, Provinces, Nations and other 
such jurisdictions have tax or registration databases, 
which currently contain insurance status information on 



objects of value recorded and also perhaps registered in 
that jurisdiction. Instant access to database(s) in which the 
status data cannot be known to be accurate is simply a 
potentially better method of obtaining data that still can- 
not be trusted and properly used. The present invention 
provides instead, access to a database resident on either a 
dedicated server or server node in either a secure private 
facility or in a government computer system facility dedi- 
cated for such use. Access to government-maintained 
databases is typically provided, under some security pro- 
visions, to most governmental agencies, such as "DMVs", 
(Departments of Motor Vehicles), State Police, the Courts, 
and also, in many cases regarding objects such as land 
and buildings, to any member of the general public. Ac- 
cess to the dedicated database, (which is not typically 
maintained by a jurisdiction), is available to anyone with 
telephony and/or computer access. Access to this system 
to obtain status can be made via direct, intranet, or inter- 
net link, but those methods have been available previously 
in prior art. The present invention adds one new method 
of status verification, which is telephone access, including 
"IVR", (Interactive Voice Response) and touch-tone use as 
well. This is made possible by use of the aforementioned 



unique identifier, (also referred to as the "UC" or "unique 
code" in regards to the present invention). 

[0010] Additionally, while numerous patents have provided po- 
tential answers to the tracking of objects of value, as dis- 
closed in the previously referenced U.S. Patent No. 
6,076,064 to Rose, Jr., and disclosed in U.S. Patent 
6,233,563 to Jefferson, et al.), no prior art has properly 
addressed the issues of ensuring that status data is cur- 
ren. Tthis invention does so by providing software that 
ensures status data is always current and reflects exactly 
and only what each insurer says the status of each policy 
is at any specific time. 

[001 1] one attempt to protect against fraud in motor vehicle 
transactions is disclosed in the aforementioned U.S. 
Patent Number 4,989,144 to Barnett III. It teaches to iden- 
tify discrepancies in existing vehicle title information by 
gathering recent title transaction data from a plurality of 
sources indexed by the VIN. It then adds records to a 
master database having a plurality of standard variable 
format transaction records indexed by the VIN. When a re- 
port is requested, all records indexed by the same VIN are 
selected and discrepancies are identified by "contextual 
analysis". One of the numerous problems associated with 



this system is that it relies on a comparison of records 
kept by others. It does not correct any discrepancies in 
those records, nor does it provide any means for eliminat 
ing the errors when the data is originally input into the 
various databases. Further, it requires that data be kept 
by various, independent entities, and then redundantly re 
searched time and time again (even for that same vehicle) 
because that vehicle may change jurisdictions and/or 
owners many times in its life cycle. Further, it will be 
readily apparent that 1000 vehicles can be reviewed "con- 
textually" with ease, but 200 million vehicles become 
much more difficult. The present invention, while not a 
tracking system and not designed to ensure that all regis- 
tration elements are correct and legitimate, does provide 
one certain data element that can be used to protect the 
parties involved. The "UC", ("unique code" or unique iden- 
tifier), can be linked to an exact vehicle, (or other object 
of value in exactly the same manner), and the insurance 
status instantly known, thus eliminating all problems as- 
sociated with the use of incorrect identifiers, (which are 
very common), and changes regarding previously-refer- 
enced "contextual analysis" issues. 
2 1 There are numerous additional problems with all previous 



methods of insurance verification. Many insurance com- 
panies allow for premiums to be paid in monthly install- 
ments. Insurance policy identification cards or other doc- 
uments are issued after the first payment indicating that 
the policyholder is insured for a certain period of time, 
generally either six months or a year. If additional pre- 
mium payments are not continued, the insurance cover- 
age will no longer exist even though the policyholder or 
owner's insurance documentation will indicate that insur- 
ance is in effect for additional months. Prior to the devel- 
opment and implementation of the present invention, 
there has been no adequate verification technique capable 
of detecting lapses in insurance coverage. 
[0013] This invention ensures that any check of status, at regis- 
tration, (including "e-registration"), inspection, court ap- 
pearances, or any other location where a jurisdiction re- 
quires or may require such a status check, will result in an 
instant and totally accurate status response. This provi- 
sion is due to "gleaner" software, currently written in Java 
and XML, but which might be written in any one of several 
current or future platforms and operating systems that is 
"agnostic", (transparent to and accepting of various plat- 
form and operating system software products), which 



monitors data streams without passing firewalls or inter- 
facing with insurer or government databases. It looks for 
the manufacturer's identification number, or similar iden- 
tifier, (or it may be the policy number in the case of a "de- 
activate" notice), then seeks status data in another field, 
(an approval code, renewal, or a "deactivation" notice, 
(suspension, cancellation or termination), and upon see- 
ing both of the two required data elements, captures 
those fields and also the policy number and/or other 
field(s) as directed by the insurer and/or jurisdiction, and 
as directed by decisions recorded previously using the 
present invention's table-driven set-up system. The 
present invention relates therefore, to the retrieval of very 
limited data from either a data stream of files in under- 
writing, (which may be on either an insurer server or on a 
server providing such services on behalf of an insurer) or 
other approval system, (an element the present invention 
refered to as "FEG", or "Front End Cleaner", or a database 
with approved policy initiations, (both new policies and 
additional vehicles being added to existing policies). Like- 
wise, the present invention is used in the same manner 
regarding the "REG" or "Rear End Gleaner" which also 
monitors and gleans from report data streams, (as it is 



there that notices of policy terminations, suspensions and 
cancellations, etc., occur). The forwarding of data from 
both gleaners via the insurer's existing reporting commu- 
nication system, and the maintenance of such retrieved 
data in multiple databases for instant access can then be 
effected. Since the only data captured and maintained is 
supplied directly by insurers, and no modifications to this 
data is possible, all parties are assured that such informa- 
tion supplied is accurate. For those insurers who wish to 
use them, two additional versions of the software are 
available, but both operate in general terms as described 
previously. One of these additional versions allows an in- 
surer to use the software directly under full control, so 
that control of when the gleaner is activated is determined 
by same, but the software described earlier accomplishes 
exactly the same task in the identical manner otherwise, 
and there is also another version which allows an insurer 
to simply send "book of business", (entire files), to the 
dedicated database which, identifying the insurer's NAIC, 
(National Association of Insurance Commissioner's) five 
digit insurer identification code, and activating that spe- 
cific profile, (choices documented previously by that in- 
surer), then "gleans" the data as described previously, as- 



signing a "UC" to the file, keeping only the very limited 
data required for operation of the present invention and 
immediately returning these same files with their assigned 
"UCs". This same version can be used to handle insurer 
legacy data and government databases of insured vehicles 
in exactly the same manner. In short, the present inven- 
tion is not limited to use in a specific site, but can accom- 
plish the assigned tasks involved in any of a number of 
locations. The function of the present invention, in all 
cases however, never changes. 

[0014] | t j S essential that the retrieving of such data, the mainte- 
nance of this data and the method of access to same, all 
occur in a non-invasive manner. This is provided by the 
present invention. No names addresses, or other personal 
data is maintained. Unfortunately, this means that the 
present invention cannot, for example, provide informa- 
tion on a potential terrorist. Fortunately, it also means 
that the present invention cannot be used to invade the 
privacy of any insurance policyholder and can also not 
target any person or group. 

[0015] it is important to provide an overview of both the internet 
and relational databases in explaining the use of the in- 
vention. 



[0016] An important use of computers is the transfer of informa- 
tion over a network. Currently, the largest computer net- 
work in existence is the Internet. The Internet is a world- 
wide interconnection of computer networks that commu- 
nicate using a common protocol. Millions of computers, 
from low-end personal computers to high-end super 
computers are coupled to the Internet. 

[001 7] The Internet grew out of work funded in the 1960s by the 
U.S. Defense Department's Advanced Research Projects 
Agency. For a long time, the Internet was used primarily 
by researchers in universities and national laboratories to 
share information. As the existence of the Internet be- 
came more widely known, many users outside of the aca- 
demic/research community (e.g., employees of large cor- 
porations) started to use the Internet to carry electronic 
mail. 

[0018] | n 1989, from Geneva, Switzerland, a new type of infor- 
mation system known as the World-Wide-Web ("the Web") 
was introduced to the Internet. Early development of the 
Web took place at CERN, the European Particle Physics 
Laboratory there. The Web is a wide-area hypermedia in- 
formation retrieval system aimed to give wide access to a 
large universe of documents. At that time, the Web was 



known to and used by the academic/research community 
only. There was no easily available tool, which allowed a 
technically untrained person to access the Web. 
[0019] | n i993 j researchers at the National Center for Supercom- 
puting Applications (NCSA) released a Web browser called 
"Mosaic" that implemented a graphical user interface 
(GUI). Mosaic's graphical user interface was simple to 
learn, yet powerful. The Mosaic browser allows a user to 
retrieve documents from the World-Wide-Web using sim- 
ple point-and-click commands. Because the user does not 
have to be technically trained and the browser is pleasant 
to use, it had the potential of opening up the Internet to 
the masses. 

[0020] The architecture of the Web follows a conventional client- 
server model. The terms "client" and "server" are used to 
refer to a computer's general role as a requester of data 
(the client) or provider of data (the server). Under the Web 
environment, Web browsers reside in clients and Web 
documents reside in servers. Web clients and Web servers 
communicate using a protocol called "Hypertext Transfer 
Protocol" (HTTP). A browser opens a connection to a 
server and initiates a request for a document. The server 
delivers the requested document, typically in the form of a 



text document coded in a standard Hypertext Markup 
Language (HTML) format, and when the connection is 
closed in the above interaction, the server serves a passive 
role, i.e., it accepts commands from the client and cannot 
request the client to perform any action. 

[0021] The communication model under the conventional Web 
environment provides a very limited level of interaction 
between clients and servers. In many systems, increasing 
the level of interaction between components in the sys- 
tems often makes the systems more robust, but increas- 
ing the interaction also increases the complexity of the in- 
teraction and typically slows the rate of the interaction. 
Thus, the conventional Web environment provides less 
complex, faster interactions because of the Web's level of 
interaction between clients and servers. 

[0022] The development of relational databases such as Oracle, 
and SQL has revolutionized business use for vehicle insur- 
ers and the emergence of XML, Java and similar efficient, 
system and platform-independent, ("agnostic"), software 
tools, with the development and supply of ever-more so- 
phisticated "open source" application software based on 
such relational databases for insurers, continues to revo- 
lutionize that industry. While the present invention does 



not require access to any vehicle insurer or governmental 
relational database to operate, it must support the use of 
such databases on behalf of insurers and governments, it 
uses such a database to provide information form its own 
dedicated server, and it uses software and technologies 
developed for both relational databases and internet use, 
such as XML and Java, to accomplish its tasks. 
[0023] it's difficult to imagine a world without databases. Every 
time you withdraw cash from an ATM, make airline reser- 
vations, or charge something on your credit card, 
database systems are working behind the scenes. Since 
the development of the relational database model in 
1970, database technology has evolved rapidly and is now 
essential to just about all transaction processing and 
business intelligence applications. This is increasingly true 
of the insurance industry. This evolution continues, with 
innovations such as Real Application Clusters and inte- 
grated XML capabilities. From their beginnings, Relational 
database companies like ORACLE, Sybase, Informix, Ingres 
and IBM, were dedicated to a philosophy of "portability, 
compatibility, and connect ability", the very essence of 
open-system computing. In contrast to closed, proprietary 
approaches that lock a customer into a particular vendor's 



solution, the open systems market allows customers to 
benefit from the lower costs and faster rates of innovation 
that are the result of competition, and these relational 
databases continue to be positioned as the cornerstone of 
insurer computing systems, as insurers move away from 
older technologies. In the world of underwriting, so im- 
portant to the use of this invention, the value of relational 
databases is unquestioned. 

[0024] The relational database revolution began when IBM re- 
searcher Dr. Edgar Codd published the paper "A Relational 
Model of Data for Large Shared Data Banks." Oracle Chair- 
man and CEO Larry Ellison, along with friends and former 
coworkers Bob Miner and Ed Oates, had started a consul- 
tancy called Software Development Laboratories (SDL) in 
Silicon Valley. Ellison and Miner read Codd's paper and 
another paper published in the November 1976 IBM Jour- 
nal of R&D that described a preliminary version of the SQL 
language. Ellison saw tremendous business potential in 
database software, and he and his cofounders at SDL be- 
gan building what would become the first commercially 
available relational database management system. 

[0025] what continues is a short historical overview of relational 
database development, focusing on Oracle, which is per- 



haps the most popular of both insurance company and 
State government relational database platforms. The pro- 
vision of this historical insight is intended to further ex- 
plain the use of relational databases for insurers, State 
governments, and in support of the present invention. In 
providing this, it hoped that it will also be clear why it is 
so important that this invention operate without passing 
firewalls or require interface with such databases under 
the control of insurers or governments. The role of the in- 
vention is to support the systems of the insurers and gov- 
ernments, requiring as little modification as possible and 
none at all of their relational databases. 

[0026] The SDL Management, referenced above, called their fin- 
ished product Oracle, after the code name of a CIA- 
funded project Ellison and Miner had worked on at a pre- 
vious employer, (Ampex). Later, the CIA was one of Ora- 
cle's first customers and remains one of its largest. Later, 
the name of SDL was changed to RSI, then to Oracle to 
identify more closely with the product. 

[0027] Oracle was first offered commercially in the summer of 
1979 on Digital Equipment PDP-11 minicomputers. The 
new database product incorporated a reasonably complete 
implementation of SQL, including sub queries, joins, and 



other features, but it was not very reliable and lacked cer- 
tain important functionality such as transactions. This first 
version was called Oracle 2 because it was decided that 
few customers would buy the product if they knew it was 
the first version. 

[0028] | n 1983, a new version of Oracle was released that was 
entirely re-written in the then-new C programming lan- 
guage, increasing its portability beyond the range of op- 
erating systems that ran on the DEC PDP-11. Oracle Ver- 
sion 3 also introduced atomic execution of SQL state- 
ments and transactions. This meant that unlike in Oracle 
version 2, a SQL statement would succeed or fail in its en- 
tirety, and transactions would be either committed or 
rolled back fully. It also introduced non-blocking queries, 
using data saved in a "before image file" for both queries 
and transaction rollback, thus avoiding the use of read 
locks, (even though its throughput was limited by use of 
table-level locking). 

[0029] a year and a half later, in 1984, Oracle 4 was released 

with improved stability and a new feature called read con- 
sistency - the assurance that a query will see a set of data 
that remains consistent during execution. This meant that 
money shifted between policies or bank accounts during a 



query would not be miscomputed and employees, added 
to an HR data base during a query not be miscounted. 

[0030] | n 1985 and 1986, Oracle released versions 5 and 5.1 

which were remarkable in that they were among the first 
client/server RDBMS, (Relational Data Base Management 
Systems), so that business applications running on desk- 
top PCs (clients) could access a database server over a 
network. It was this and similar RDBMS that so greatly im- 
pacted the prior art referenced and has served in helping 
make the present invention possible. Version 5.1 also 
supported distributed queries, allowing a single query to 
access data stored in multiple locations. 

[0031] Oracle version 6, released in 1988 was scalable. It intro- 
duced a new architecture for enhanced performance, scal- 
ability and availability. One of the most important features 
was row-level locking - a transaction performing writes 
locks only the affected rows (not an entire table), resulting 
in improved system throughput when many users access 
the same data. It also had backups, allowing a database to 
be backed up while in use. 

[0032] After years of intense research, Oracle 7 was released in 
1992, and introduced new performance features, dis- 
tributed transactions, administration enhancements, new 



tools for application development, and security methods. 
Oracle 7 also included new capabilities such as stored 
procedures, triggers, and declarative referential integrity, 
making the data base programmable and able to enforce 
business rules. 

[0033] | n i997 j Ellison unveiled Oracle 8, which laid the ground- 
work for supporting the internet, network computing and 
new types of information. It also included support for ob- 
ject-oriented development and multi-media applications. 
This was followed fifteen months later with Oracle8i, (i for 
"internet"), which supported internet-based activities and 
applications. Oracle 8i became the first database to incor- 
porate a native Java runtime environment, allowing stored 
procedures and triggers to be written in the Java lan- 
guage, which was gaining popularity. It also supported 
SQLJ, an open standard for embedding SQL database 
statements into client or server Java code, and Oracle in- 
terMedia for managing multimedia content. 

[0034] Oracle 9i, was certainly Oracle's most significant release 
ever, and contained technologies that forever changed he 
computing landscape. Among its 400 new features is Real 
Application Clusters, a unique technology that permits 
multiple clustered computers to share access to a single 



database for new levels of scalability, availability, and af- 
fordability. Besides offering greatly improved security, it 
also contains integrated business intelligence. Release 2 
of "9i" made Oracle a native XML database; it contains a 
powerful facility for storing and accessing XML docu- 
ments, putting SQL and XML on equal footing. 

[0035] Oracle was the first RDBMS available on Linux, and has 

contributed key technologies to the open source commu- 
nity, (memory management, I/O, and a clustered file sys- 
tem). In addition to supporting Linux, applications have 
been developed that run on clusters of commodity blade 
servers, or grids. Much like the utility grid that powers 
your home, grid computing delivers computing as a util- 
ity. On the server side, grid computing is about resource 
allocation, information sharing and high availability. Re- 
source allocation ensures that everyone gets the process- 
ing cycles he or she needs and that resources don't sit idle 
if requests are pending. Information sharing ensures that 
information and applications are available where and 
when they're needed. 

[0036] insurers typically update policy "adds", (newly insured ob- 
jects of value covered by a new policy or added to an ex- 
isting policy), only once each day. In some cases, over 



weekends or holidays, an "add" or "initiation" may take 
several days prior to being recorded in the "stacks", 
(central files) of an insurer. In the interim, a "binder" 
(temporary document providing temporary coverage), is 
issued. In some cases, insurers may also report suspen- 
sions, terminations, cancellations, etc., only once each 
day, or as in the above case, only after a weekend or holi- 
day period. The present invention is unaffected by any 
such insurer decisions and activity. It only reflects the in- 
surer's decision as to coverage, and can make no modifi- 
cation^) to same. 
[0037] insurance binders as discussed above, provide a notice of 
temporary insurance coverage. Because underwriting sys- 
tems, upon approval of an "add"or "initiation", are also the 
business units that approve the issuance of a binder, such 
business units can provide additional, dramatic benefits to 
insurers by either using the unique identifier, "UC", 
(unique code), as the binder number or by linking said 
unique identifier to the binder number. This feature bene- 
fits vehicle insurance policyholders in that it allows instant 
registration or asset use, should verification of active in- 
surance status be required. If, for some reason, the "UC" 
used in registration or reporting is not soon reported to 



the appropriate entity/authority then "deregistration" or 
cancellation can then occur. 

[0038] Policyholders can also benefit from the ability to check 

status of their insurance, (or that of anyone else), if a reg- 
istration or insurance identification document is supplied, 
by the use of any telephone. An "800" telephone number 
and the UC that identifies that particular combination of 
item identifier, (manufacturer's identification number, 
"VIN" if a vehicle) or registration identifier and policy, (or 
other elements as directed by an insurer or government 
agency), can be printed on a registration or policy identifi- 
cation document and, this in turn provides instant access 
and response over any telephone. Because no names, ad- 
dresses or other personal information is maintained, and 
only a code is used, the system is inherently non-invasive 
and privacy issues remain fully supported. 

[0039] The benefits to insurers, in addition to supplying benefits 
to their policyholders by improving service, are dramatic. 
Their use of the "UC" enables their control of binder activ- 
ity in a manner not possible previously except with "cap- 
tive" agencies, (agencies that write for only one insurer 
and are on-line with same during business hours), and 
this greatly benefits insurers by reducing fraud losses. 



Premium diversion, "fund float", back dated policies and 
many types of "repair scams", can be instantly eliminated. 
While the system is capable of only very limited reporting, 
it can at least report when any product identifier is cov- 
ered by two or more policies, then notify each insurer in- 
volved that there is a possible "repair or transfer scam" 
underway. It is archival, so it can also provide authorized 
insurers and government entities with information regard- 
ing periods and lapses of insurance coverage. Again, the 
APIs (Application Program Interfaces, also known as "soft- 
ware hooks"), are provided to each insurer to capture and 
use the "UC" in any manner desired. The decision(s) re- 
garding how to best use these benefits remain, at all 
times, under the control of the insurer(s) and/or govern- 
ment(s) involved; it is simply the unique features of the 
present invention that make them possible. 
[0040] Many States now require insurers to report insurance in- 
formation electronically. The insurers and governments do 
so now via FTP, x.12, x.25 or similar communications 
protocols. The present invention requires no changes in 
this regard. The present invention enables a jurisdiction 
and insurer to enjoy the dramatic benefits associated with 
current reporting, without forcing unnecessary change, 



but is "pre-set" to automatically provide daily reporting, 
which, with binder use, ensures that information remains 
current and accurate. This feature can, however be 
changed by any insurer or authorized government entity 
controlling the verification database and using this sys- 
tem. The insurer or said governmental entity can deter- 
mine to have an "open pipe" connection, operational 
"around the clock", which supplies status data as it occurs 
or, if a very small insurer is responsible for reporting, said 
insurer may prefer to report only on the rare occasion that 
it has a policy change for that particular State. It is, after 
all, not the present invention's role to dictate to insurers 
what the status of any given policy should be or how it 
should be reported, but rather to simply enable the in- 
surer or governmental entity in control to report as each 
decides. Likewise, it is the insurer's legal responsibility to 
provide coverage between the time of binding and report- 
ing, so the present invention's data is, by definition, al- 
ways current. Since the dedicated database involved is an 
exact reflection of what the insurers say their policy status 
is on any given policy, it is clearly in their own best inter- 
est to ensure prompt reporting. The present invention 
claims to be the first-ever "on-line/real-time" insurance 



status verification system, and is exactly that, as its status 
data is always accurate according to the insurers, and no 
other factor influences reporting of status, as there are no 
additional time constraints or delays. 

[0041] The present invention provides access to status data at 
any time to anyone who has access to a computer, wire- 
less PDA, telephone or similar device. It provides a simple, 
secure method of accident and theft reporting, and It en- 
ables, for the first time ever, everyone to fully participate 
in collective security, while providing better insurance 
service, increased respect for the law, and over time, 
lower insurance rates. 

[0042] The tools and methodology now exist therefore, to pro- 
vide an on-line/real-time, automatic and non-invasive in- 
surance verification system that resolves all problems as- 
sociated with prior art and this document records the ex- 
isting system thus created. 
Summary of Invention 

[0043] This invention provides accurate insurance status infor- 
mation for any object of value in real-time without regard 
to insurer or jurisdiction, location, language, type, time, 
and also the internal operations, software platform, and 
communications protocols used by insurers and/or gov- 



ernmental entities. It is an insurance verification, not an 
insurance reporting or tracking system, and because it 
maintains no personal data of any kind, and can modify 
no record, it can deliver only very limited features regard- 
ing reporting or tracking. The present invention can how- 
ever, provide absolute assurance of current insurance sta- 
tus at all times, provides a unique method of access which 
resolves all current failures, allows access by any person 
with computer, wireless device using common protocols 
or telephony devices, access to status and the ability to 
report accidents and thefts. It is non-invasive, providing 
complete privacy for all parties involved. This invention 
further ensures that any check of status, at insurer or 
governmental registration, (including "e-registration"), in- 
spection, or any other location and time when and where a 
jurisdiction or insurer requires such a status check, will 
result in an instant and totally accurate status result. It 
can be implemented due to government regulation, by the 

choice of insurers, or by both. 
Brief Description of Drawings 

[0044] These Figures describe the two separate elements of the 
present invention. Figures 1 through 4 describe the 
methodology involved in establishing and maintaining 



data available for access, while Figure 5 describes the ac- 
cess methods used to safely obtain said data for verifica- 
tion and the very limited reporting methods available. Fig- 
ure 6 describes the methodology of the "gleaner", (file 
field extraction and related methodology and systems), 
and Figure 7 is a sample page of a code sheet used to 
demonstrate how the gleaner element recognizes and 
captures data. More specifically: Figure 1 is a logical flow 
chart of the overall method of the invention at origination, 
(insurer or government site). Figure 2 is a logical flow 
chart of the overall method of the invention during data 
distribution and use. Figure 3 is a system overview pro- 
viding more detail of Figure 1 in regards to the use of the 
present invention at an insurer's site. Figure 4 is a system 
overview providing more details of Figure 1 in regards to 
the use of the present invention at a government site. Fig- 
ure 5 is a logical flow chart of the elements of the present 
invention used to access the data maintained by the 
present invention. Figure 6 is a logical block diagram 
showing the overall method of the invention's file extrac- 
tion element. Figure 7 is a sample code sheet demonstrat- 
ing a data stream structure common to insurers. 
Detailed Description 



[0045] The present invention seeks to overcome the deficiencies 
of prior art by providing a system and method for in- 
stantly and accurately verifying the existence of insurance 
without respect to insurer, location jurisdiction, language, 
type of insured item, time, and also the internal opera- 
tions, software platform and communications protocols 
used by insurers and/or governmental entities. It can ac- 
complish this in real-time, in total accuracy and in a non- 
invasive manner. It can be implemented due to govern- 
ment regulation, by the choice of insurers, or by both. 

[0046] According to exemplary embodiments of the present in- 
vention, it provides required government reporting on be- 
half of insurers and also for the production of insurance 
policyholder documents and/or identification card(s), 
binder(s) or similar documents, (if required), eliminates 
many types of insurance fraud, including false insurance 
identification cards and other documentation, "back- 
dated" policies, "fund float", various "repair scams", and it 
dramatically reduces other costs to insurers, especially 
losses involving false property claims and uninsured vehi- 
cles. 

[0047] All information supplied by the present invention is accu- 
rate at all times because it is always and only an exact re- 



flection at any moment on any policy as reported by the 
insurer involved. 

[0048] implementation takes only minutes and except for the 

provision and assignment of a unique identifier referenced 
to two elements and optional government requirements, 
its use is determined entirely by the insurer. The insurer 
can even determine the manner and frequency of the 
present invention's use, provided said determination does 
not conflict with governmental requirements, (if any), and 
can determine the location of its use, even if at a site re- 
mote from that of the insurer, (such as the present inven- 
tion's central, dedicated server or a governmental entity). 

[0049] The present invention provides insurance verification via 
telephony or internet access at any time and to anyone 
without limitation because it is not limited in use to insur- 
ers or government agencies, but available to all. 

[0050] The present invention is further distinguished by its ability 
to provide information on any policy without respect to 
location, jurisdiction, type of insured item, time, and also 
the internal operations, software platform, and communi- 
cations protocols used by insurers and/or governmental 
entities. 

[0051] The present invention is further differentiated in that it 



has no requirement to maintain names, addresses, or 
other personal details so that privacy issues are fully sup- 
ported and no person or group can be identified and tar- 
geted in any manner. 

[0052] The present invention is further differentiated in that it 
extracts and maintains status data without the require- 
ment to utilize internet or telephony connections to con- 
tact an individual insurer regarding a specific policy or 
group of policies and with the attendant privacy, connec- 
tivity, and security issues involved in such prior art. 

[0053] The present invention is further distinguished from prior 
art in that, extracting data from data streams or databases 
other than central "stacks", (from data bases of pre- 
approved initiations, "adds"or terminations, suspensions, 
and cancellations), rather than said central insurer 
databases, it is non-invasive to said insurer databases. 

[0054] The present invention is further differentiated in that, be- 
cause of its unique architecture and features, the require- 
ment to obtain and maintain large amounts of data does 
not exist, and, as a consequence, file sizes are exception- 
ally small, and response to and from the data maintained 
in the dedicated database is almost instantaneous. 

[0055] The present invention is further distinguished by its ability 



to provide accurate information regarding multiple insur- 
ers, (an individual insurer may be able to provide current, 
accurate status regarding their own policies, but can sup- 
ply no such information about the policies of other insur- 
ers). 

[0056] The present invention is further distinguished by the ex- 
traction of data fields meeting governmental requirements 
and the automatic supply of same to government entities 
as designated by governmental requirements in order to 
meet the governmental reporting requirements of insur- 
ers. 

[0057] The present invention is further distinguished by its ability 
to provide information with total accuracy as it is, by defi- 
nition, always and only a reflection of the exact status re- 
ported by insurers and said invention can modify no ele- 
ments of any insurer record of any kind, at any time. 

[0058] it is an object of the present invention to provide a cen- 
tralized uniform system for maintaining up-to-date and 
accurate insurance status for any given insurer, jurisdic- 
tion, and group or association of insurers. 

[0059] it is another object of the present invention to provide a 
centralized, uniform system for maintaining up-to-date 
and accurate insurance status for any governmental en- 



tity(ies) and related organization(s), and association(s). 

[0060] it is another object of he present pesent invention to pro- 
vide a centralized uniform system for maintaining up- 
to-date and accurate insurance for any given combination 
of insurer(s) and related organization(s), association(s), or 
business entity(ies). 

[0061] it is yet another object of the present invention to provide 
information on any policy without respect to insurer, loca- 
tion, jurisdiction, language, type of insured object of 
value, time, and also the internal operations, software 
platform, and communications protocols used by insurers 
and/or governmental entities. 

[0062] it is another object of the present invention to reduce the 
incidence of insurance fraud in Society, protecting both 
insurers and the public from such fraud. 

[0063] it is another object of the present invention to provide for 
a single document with a single, master UC, (unique iden- 
tifier), to make reference to the insurance status of multi- 
ple objects of value, each of which has, in turn, their own, 
individual UC assigned as described in both the preceed- 
ing and following sections of this document. 

[0064] n is another object of the invention to enable law enforce- 
ment officers to know with certainty, the current status of 



iregarding a specific object of value. 

[0065] it is another object of the invention to enable courts to 
know with certainty, the current status of insurance re- 
garding a specific object f value on the date of citation 
and/or summons, and/or seizure and on the date prior to 
same, in order to determine that insurance was not pur- 
chased later the same day. 

[0066] it is another object of the invention to enable government 
staff to know with certainty, the current insurance status 
of a specific object of value at time of registration, regis- 
tration renewal, and at any other time required or desired. 

[0067] it is another object of the invention to enable insurers to 
know with certainty, the current status of insurance re- 
garding a specific object of value, to know periods of prior 
coverage and to know if there are two or more policies as- 
signed to a particular identifier/registration number. 

[0068] n is another object of the invention to extract and main- 
tain status data without the requirement to utilize internet 
or telephony connections to check an individual insurer 
regarding a specific policy or group of policies and with 
the attendant privacy, connectivity, and security problems 
common to such prior art. 

[0069] n is another object of the invention to extract data from 



data streams rather than passing firewalls and/or inter- 
facing with central insurer databases being at all times, 
non-invasive to said insurer databases. 

[0070] it is another object of the invention that, because of its 

unique architecture and features, it has no requirement to 
obtain and maintain large amounts of data and, because 
as a consequence of this, file sizes are exceptionally 
small, and as a further consequence, response time re- 
garding queries to and responses from the dededicated 
database is almost instantaneous. 

[0071] | t j S another object of the invention that the supply of its 
issued unique identifiers for use by insurers as binder 
numbers, (or referenced by binder numbers), enables pol- 
icyholders and/or owners to immediately effect registra- 
tion(s), purchase(s), sale(s) or other transactions desired 
without delay. 

[0072] n i S another object of the invention that the supply of its 
issued unique identifiers for use by insurers as binder 
numbers, (or referenced by binder numbers), enables 
owners of insured objects of value to use same immedi- 
ately in compliance with any regulations, legislation, con- 
tracts, or agreements that require uch compliance. 

[0073] n is another object of the invention that the supply of its 



issued unique identifiers for use by insurers as binder 
numbers, (or referenced by binder numbers), and also as 
the established means of access using same to insurance 
status information in future enables proper monitoring so 
that the failure to make a payment or other action that re- 
sults in suspension, termination, or cancellation of a pol- 
icy can be so reported and known the instant such action 
is determined and reported by insurer. 

[0074] | t j S another object of the invention that as the addition of 
only the previously referenced "UC" (unique code also re- 
ferred to as "unique identifier"), and a telephone number 
or web page which provides access to the previously ref- 
erenced dedicated database for verification purposes us- 
ing same and accessing insurance status, added to a 
printed paper, plastic, or other material insurance identifi- 
cation document, thus allowing a simple and accurate sta- 
tus verification, constitutes a complete anti-fraud device. 

[0075] it is another object of the invention that it is to be further 
distinguished by the extraction of data fields meeting 
government requirements and the automatic supply of 
same to identification documentation manufacturers for 
production and supply of insurance policy identification 
documents. 



[0076] [0075] It is another object of the invention to provide in- 
surers with all software system requirements to effect au- 
tomatic government reporting of all insurance status re- 
quirements. This to be accomplished by the extraction of 
data fields meeting said governmental and insurer re- 
quirements from any insurer underwriting system and the 
extraction of said data fields from any insurer status re- 
porting system, avoiding at all times any insurer central 
database(s), and the automatic supply of same extracted 
data from the aforementioned sources to government en- 
tities as designated by said government requirements in 
order to meet the governmental reporting requirements of 
insurers. 

[0077] it j S another object of the invention, as an alternative to or 
in conjunction with above, to provide governmental enti- 
ties with a software system requirements to effect auto- 
matic governmental reporting that meets all insurance 
status requirements. This is to be accomplished by the 
extraction of data fields meeting said governmental and/ 
or insurer requirements from any insurance data initial "in- 
take" processing system and/or the extraction of said 
data fields from any insurance data reporting system, and 
the automatic supply of same extracted data from the 



aforementioned source(s) to insurers and other parties as 
determined by said government entity(ies) and/or in- 
surers). 

[0078] it is another object of the invention that it can be, if an in- 
surer wishes, automatic in operation so that once installed 
no additional involvement of said insurer is required. 

[0079] it is another object of the invention that it can be, if an in- 
surer or governmental entity wishes and so used at an- 
other site apart from that of insurer and/or government 
entity responsible for processing and maintaining insurer- 
supplied data. 

[0080] it is another object of the the invention that, except for 
the extraction of data field elements required by govern- 
mental entity(ies), if any, and the assignment of a unique 
identifier to at least two such data field elements, the 
control of the present invention and each module therein, 
remains at all times with the insurer, who can activate or 
deactivate each at will, provided governmental require- 
ments are met and data is sent on a timely basis so as to 
insure coverage is shown as "active" when the binder ex- 
pires. 

[0081] it is another object of the invention, in regards to vehicles 
and/or equipment owners, users and drivers to know with 



certainty, the current status of insurance regarding a spe- 
cific vehicle or item of equipment. 

[0082] | t j S another object of the invention to enable business 

owners, including rental agencies, vehicle and equipment 
dealers to know with certainty, the current status of insur- 
ance regarding a specific object of value. 

[0083] it is another object of the invention to enable pedestrians; 
property owners or others involved in an accident or a 
claim to know with certainty the current status of insur- 
ance regarding a specific object of value. 

[0084] n j S another object of the invention to enable any member 
of the public to know with certainty, the current insurance 
status of on an object of value. 

[0085] it is another object of the invention to ensure that no poli- 
cyholder can be identified personally as no personal infor- 
mation of any kind is maintained, and that no individual 
or group can thus be "targeted" in any way. 

[0086] it is another object of the invention to protect insurers 

against theft and theft-related fraud, especially in regards 
to false documents, "fund float", premium diversion, and 
"repair scams". 

[0087] n is yet another object of the invention to assist in the 

elimination of the "after-market"for stolen items and their 



sub-parts and therefore, deter or eliminate such theft and 
theft-related fraud. 

[0088] it is yet another object to eliminate the redundancy and 
associated costs and wasted effort and time involved 
when various parties maintain separate records of the 
same transaction(s). 

[0089] it is yet another object to eliminate potential confronta- 
tions between those seeking to register or record an in- 
sured object of value and government employees and 
others responsible for assisting in such registration, by 
removing the burden of questionable insurance status 
from both parties. 

[0090] it is another object to ensure that the system represented 
by the present invention be maintained in a congruent and 
continual manner, be backed-up by redundant systems 
and be available for query with no inoperable period(s). 

[0091] n is another object to provide governmental entities, and 
especially law enforcement with a means of automatic no- 
tification of accidents or theft(s) to insurers involved in a 
manner that does not subject the transmission of infor- 
mation to or from said insurer to invasive methods and 
potential privacy concerns. 

[0092] n is another object to provide policyholders with a means 



of automatic notification of accidents and thefts to their 
insurers in a manner that does not subject the transmis- 
sion of information to or from said insurer to invasive 
methods and potential privacy concerns. 
[0093] it is another object of this invention to provide a system, 
as aforesaid, which compensates for delay in the recorda- 
tion of records in a government insurance status 
database. Thus, it is an object of the present invention to 
provide a centralized, uniform system for maintaining up- 
to-date and accurate insurance status for any given juris- 
diction. 

[0094] it i S still a further object of this invention to provide a sys- 
tem which supplies information which is totally accurate 
as it is, by definition, always and only an exact reflection 
of the exact status reported by multiple insurers and said 
system can modify no element(s) of any insurer record of 
any kind or at any time. 

[0095] it is yet another object of this invention to provide accu- 
rate information regarding multiple insurers' policies and 
to then provide reports regarding same to insurers in the 
event that a single insured item of value has two or more 
policies associated with it, as that may be determined to 
be a possible case of fraud. 



[0096] ^ is yet anther object of the present invention to provide 
insurance verification via telephony methods involving 
"IVR", (Interactive Voice Response), so as to enable users 
to obtain status information more easily. This is enabled 
by the use of the "UC" (unique code, a form of unique 
identifier described previously). 

[0097] The drawings or figures included in this document dis- 
close illustrative embodiments of the invention. Given the 
benefit of this disclosure, those skilled in the art will ap- 
preciate that various modifications, alternate construc- 
tions, and equivalents may also be employed to achieve 
the advantages of the invention. Therefore, the invention 
is not to be limited to the above and following description 
and illustrations, but is only to be defined by this docu- 
mentation and claims. These and other features and ad- 
vantages of the present invention may be better and more 
completely understood by reference to the preferred ex- 
emplary embodiment in conjunction with the drawings 
that follow. 

[0098] The general operational overview for the present invention 
is perhaps best demonstrated by means of the flow charts 
as seen in Figures 1 and 2, below. The process begins 
with a module referred to in the present invention as 



"FEG" or "Front End Gleaner"and is further identified as 
Module "A". When, in Fig. 1, item 1, a data stream or 
database in which initial "intake" processing is done, (and 
which may or may not be on an additional server which is 
connected to the "intake" server), and which has been set 
up via a GUI, ("Graphic User Interface"), to monitor specific 
fields, (and may also monitor both the format of data and 
specific characters therein), detects such fields as popu- 
lated and, if required, populated with the required charac- 
ters and/or formats, (predetermined by use of GUI, as il- 
lustrated in more detail beginning with Fig. 6), the present 
invention is activated. The initial field will be the Identifi- 
cation number of the object of value. That in turn, is ei- 
ther the number assigned by the manufacturer or distrib- 
utor, or a number provided by an oversight entity, 
(typically an association, retailer, or by a government en- 
tity). For example, in the case of a vehicle it would be the 
"VIN" (Vehicle Identification Number), if the system is be- 
ing used at an insurer's site or on behalf of an insurer, 
and will either be the registration number, the proposed 
registration number or a (typically temporary) process 
code if at a government site or other site operating on be- 
half of the government. If the initial field does not meet 



the first pre-determined requirements, (manufacturer's 
identification, "VIN" or registration number, proposed 
registration number, or temporary process code), the at- 
tempt ends as illustrated by item 2. 

[0099] if the initial requirement is met, then a second field, as il- 
lustrated by item 3, is read, (which constitutes the ap- 
proval code field). It the apva code does not meet the pre- 
determined requirements as created by the GUI, which 
may also require specific character(s) in said field, then 
the attempt ends as illustrated by item 4. 

[0100] item 5 illustrates the point at which a unique identifier, (in 
this case, a unique numeric number referred to in this art 
at "UC" or "unique code") can be activated and assigned. 
This is further demonstrated as being sent to Module "C", 
(Item 6). The present invention may require additional 
fields to be extracted prior extractedprior to this point, 
but the "UC", which is extracted from a dedicated 
database of available numbers and assigned randomly, 
(whereupon that "UC" is eliminated from the pool of pre- 
viously available "UCs"), can be assigned with only two 
fields, (in this case, the initial field illustrated as item 1 
and the approval code illustrated as item 3). 

[° 101 ] Item 6, as described above, illustrates that the initial ex- 



tracted data can, at this time, be made available to either 
government or insurer for use as a binder number or, (for 
similar purposes), linked to a binder number. A govern- 
mental entity may desire to use it as their temporary pro- 
cess code, as a registration number or as a link to a regis- 
tration number. It is considered advantageous to insurers 
and governments to, at this time, utilize this number by 
adding it to an additional field or to an unused field in 
their intake document file in either underwriting if this is 
an insurer operation, or in the processing file if this is a 
government operation. 

[0102] item 7 illustrates that at this time, a decision must be 

made if there are additional fields that are required by the 
table-driven interface used previously and described be- 
ginning with Figure 6. If not, then the extracted data ele- 
ments are published, as illustrated by item 8, to a site to 
be distributed later, (and identified ndident as Module 
"D"), with other results from a separate module described 
in more detail later as the "REG", or "Rear End Gleaner", 
also identified as Module "B". 

[0103] item 9 illustrates that this present invention remains, at all 
times, under the control of the insurer or government us- 
ing it and said insurer or government may further modify, 



using the aforementioned GUI, the invention for additional 
report capabilities, which would not however, begin prior 
to this specific point in the operation of the present in- 
vention. If such a change took place, the present invention 
would first determine if further fields were required to 
have data extracted, (item 10), and if not, would send the 
notice that such data was not present as illustrated in item 
11, and if there were fields that were required to have 
data extracted and those field(s) had such data, then, as 
illustrated by item 12, such data would be extracted and 
sent as illustrated by item 13 to the aforementioned Mod- 
ule "D" for distribution. 
[0104] item 14 represents the first element of Module "B"which is 
also known in the present invention as the "REC'or 
"RearEnd Gleaner". Item 14 operates in the same manner 
as item 1, except that it is monitoring different fields for 
extraction and is doing so by monitoring either a print 
stream, print database, report stream or report database, 
or any combination of these, (as they are often seen and 
utilized as all the same, and are all the same for purposes 
of the present invention). If there is no manufacturer IDs, 
"VINs", "UCs", or registration numbers, then the present 
invention remains inactive as illustrated by item 15. If any 



of those elements or other fields representing those ele- 
ments are present, then a decision must be made as illus- 
trated by item 16. If there are any of the field(s) present, 
and if required, populated with characters which represent 
any form of termination or suspension of the policy or 
registration in question, as decided by insurer and/or 
government user(s) and which would have been so desig- 
nated by use of the GUI described in Fig. 6, then this in- 
formation is held and forwarded to another element, as il- 
lustrated by item 18, if not, then the verification attempt 
ends as illustrated by item 17. 

[0105] item 18 is identical in operation and function to item 9, 
except that its use is in a different module. It allows an 
insurer and/or government to modify at this point, the 
fields to be monitored and, if populated with required 
data, extracted. Item 19 then illustrates the next step 
which is a decision based on any such changes. If there 
are none, then the file is forwarded for distribution to 
Module "D", but if so, item 20 illustrates the data element 
extraction and item 21, the data being forwarded, again, 
for distribution to Module "D". 

[0106] | tem 22 illustrates the first element of Module "C" which 
was, to some degree, described previously. The "UC" and 



related manufacturer's identification number, ("VIN" or 
similar), and policy number and/or registration number or 
other codes or data representing the policy number and/ 
or registration number are made avilable, as illustrated by 
items 23 and 24, for further use by insurer and/or gov- 
ernment. In all cases, this use is optional and the insurer 
and/or government entity(ies) may decide to use this data 
or to not use it. That use at this point is a convenience to 
all concerned but its use or lack of use is not the basis of 
any claims of the present invention. 
[0107] item 25 illustrates the point at which the present inven- 
tion prepares and then forwards the data collected by field 
extraction from the previously referenced "FEC", (also 
identified as Module "A") and the "REG", (also identified as 
Module "B"). Each insurer has been assigned a five-digit 
number by the NAIC, (National Association of Insurance 
Commissioners). This data, along with the Federally as- 
signed two character State Code, (CA, NY, GA, etc.), typi- 
cally transmitted, (as is all else), in ASCII, is now ready for 
electronic transmission. Other codes and data as previ- 
ously discussed may have been required by insurer and/or 
government and perhaps data requirements added as il- 
lustrated by items 9 and 18, and which might include for 



example, identifiers for the source, (Agent, "CSR", 
(Customer Service Representative), which may have been 
added as well, but these decisions reside with insurer 
and/or government. 

[0108] pile transfer, as illustrated by item 26, may be by x.12, 
x.25, FTP, or any of a number of methods, which is not a 
proprietary element of the present invention. Typically, 
insurers already have such communication arrangements 
in place for current electronic government reporting re- 
quirements. If not, IBM WorldNet, ATT, Sprint, and other 
telephony companies, along with a great many software 
companies are eager to handle such details and do so 
with dependability and low cost. The present invention 
has only the restriction in that data made available by it 
must be transferred securely, (SHTTP, rather than HTTP). 
The present invention is not restricted to a specific en- 
cryption and governments and insurers are encouraged to 
use their own, and perhaps that of the telephony partner 
as well, if possible. Item 27 illustrates the creation of a 
record, ("log") of all transmissions. 

[0109] Fig. 2 begins with the receipt of data from either an in- 
surer or government or site acting on behalf of insurer or 
goverand is illustrated as item 28. This is also the begin- 



ning of the present invention's "Module E". If the data is 
received from the government or site acting on behalf of 
the government, t is immediately forwarded to the in- 
surers) involved as illustrated by item 29, where data is 
sent to "F". If the data is received from an insurer or site 
acting on behalf of the insurer, the file(s) is immediately 
forwarded to the government entity(ies) involved, as illus- 
trated by item 29, where data is sent to "G", and, if insur- 
ance identity documents are required to be printed, to the 
appropriate insurance identification documents vendor, as 
illustrated by item 30, where data is sent to "H". Any and 
all file transfers are handled securely and with full encryp- 
tion. 

1 °] Additionally, item 28 utilizes pre-set criteria for file ex- 
traction as illustrated in item 31. If no further extractions 
are required, then the file is forwarded to item 33, where 
it is available for access via item 34, which represents the 
interface used for later access. Item 32 illustrates the spe- 
cific files, (and only those files) which can be further ex- 
tracted and maintained, if such further extraction is re- 
quired. If required, and once completed, the resultant data 
is forwarded to item 33 where it is stored and available for 
access as described previously. 



Figure 35 begins "Module I" which in turn, illustrates one 
of several methods of obtaining output or "end product" 
(accurate insurance status information), from the present 
invention. In this case, additional security features are 
demonstrated. An identity device representing claimed in- 
surance is inserted into, or "scanned" or "read by"), an ac- 
cess device with connectivity features. One example of 
this might be that a vehicle insurance identification card 
which is an inexpensive memory-only chip card, ("smart 
card" that nevertheless has very limited data and no pro- 
cessing capabilities and is further distinguished as having 
a fusible link, making it a "WORM" (write once/read many) 
device), is inserted into a chip card reader. As illustrated 
by item 36, the access codes on both devices must match, 
and if not, the chip card is very possibly fraudulent, in 
which case the attempt to verify status is terminated and 
other appropriate actions may then be taken as deter- 
mined by the government, insurer and others authorized 
by same. An example of just one such action is that a law 
enforcement officer might cite an individual who pre- 
sented such an identification card. Items 37 and 38 illus- 
trate these further actions. 
[° 112 ] If the access codes match, then the verification or access 



device used as further illustrated by item 39, adds its own 
unique identifier code to the identifiers contained in the 
identity instrument and transmits same as identified by 
item 40, to the location as identified by item 34, from 
which it will receive a simple "yes" or "no" response indi- 
cating that the object of value identified by the identity 
device as illustrated in item 35 is or is not currently in- 
sured. To continue with the previous example, the access 
device would incorporate GPRS, CDMA, Mobitext, GSM, 
CDMA or other communications platform and technolo- 
gies, and access either the central server of the present 
invention, illustrated in Fig. 2 as item 33, or an exact copy 
of same operating as a node or as an additional "clone" 
server inside a government "DMZ" in an intranet environ- 
ment. If we use the vehicle insurance example, it may only 
be that a law enforcement officer "runs the plates", prior 
to first leaving his or her vehicle at a traffic stop or acci- 
dent, whereupon the DMV and/or law enforcement central 
server will provide an auto query to the previously refer- 
enced dedicated node, typically on a DMV server or ac- 
cessed via intranet and located in a government "DMZ", 
which contains the identical information as that stored in 
item 33 at any time, and receive via this means, totally ac- 



curate data regarding vehicle insurance status. The ex- 
ceptionally small file size being maintained by the present 
invention further ensures a very rapid response to any 
such query. 

[0113] Many other technologies regarding identity cards and 

readers, (which would include digital watermarks, one and 
multi-dimensional bar codes, magnetic strip and text 
readers), can be utilized, although it may be argued that 
memory cards are generally agreed to be a superior alter- 
native regarding both cost and certainly provide superior 
security. In any case, no aspect of that prior art forms the 
basis for claims of the present invention. 

[0114] As illustrated by item 41, which begins "Module J"; other 
devices capable of query include computers using the in- 
ternet, PDAs (Personal Digital Assistants), using any one 
of many different communications technologies, 
(including those listed in [0120] above), and other, similar 
devices, including telephones, all of which can be used to 
query status by transmitting the "UC", (as illustrated by 
item 42), along with identification codes and headers, to 
the location as indicated by item 34, and receiving status 
information in return by the same route. 

[0115] pig. 3 begins with item 43. This item represents the 



present invention's proprietary "gleaner" technology based 
on fextraction and is another view of Fig. 1, beginning 
with item number 1 and is also referenced as "Module A". 
Likewise, item 45 is either the server or node typically 
used for underwriting by the insurer or it is a separate 
server used to spool underwriting results to, which then 
handles the gleaning (file field extraction), functions on 
files that are approved and which also then assigns the 
"UC". It additionally makes the "UC" available for use by 
the insurer, as was previously illustrated by item 6, and 
transmits all "gleaned" (data elements which have been 
extracted from files), data to the "Insurer Distribution 
Module", seen previously as item 25, (or "Module D"). This 
is also known as the "FEG" or "Front End Cleaner". 
16 ] Item 44 represents the insurer's main underwriting server, 
which is typically a separate system, isolated by firewalls, 
(item 46), from the insurer's "stacks" or main database, 
seen here as item 48. Note that the insurer's main 
database is also typically secured from the insurer's own 
reporting system, (item 49), by a firewall, (again referred 
to as item 46). Item 47 represents the transmission of 
data, still inside the insurer's system and passing no fire- 
walls, to the additional server or module, (item 51), that 



keeps the results of item 43 in memory and transmits, 
("publishes") it to the dedicated database. It typically also 
handles reporting of the file extractions from this "REG" or 
"Rear End Gleaner" as referred to as items 50 and 51, be- 
cause item 50 is the present invention software supplied 
that makes all this possible, (same as Item 43), and item 
51 is the actual physical dedicated server or node used by 
the present invention. In some cases the results or prod- 
uct of the REG may be passed directly out using an exist- 
ing transmission system, to the dedicated server, just as 
described for the FEG results above. Item 52 represents 
the transmission of data to the present invention's central 
server, (item 54), the portal used by that transmission is 
seen here as item 53. 
17 ] Item 55 indicates the transmission of data obtained by the 
file extraction process of the present invention, (in accor- 
dance with stated requirements for government and/or 
insurer acceptance and use), directly to the government 
site involved, (for example, a DMV if these are vehicle 
files). The portal receiving this data will normally be a 
node, (item 56), of the government server involved, (item 
57). Note also that the same data, (with possibly some ad- 
ditional marketing promotion and accident reporting de- 



tails, instructions or requests, in support of insurers and 
their agents), is sent to the company responsible for ID 
card production and supply, (item 58). Item 59 indicates 
that the stored data maintained by the present invention 
is now available for access and use. Fig. 5 further demon- 
strates this. 

18 ] In Fig. 3B, Item 60 represents the same as item 48 previ- 
ously, (the insurer's central database), but note that much 
else is now missing as compared with Fig. 3A. This con- 
figuration would be typical of a very small insurer with low 
volume and without a more sophisticated separation of 
internal IT, (Information Technology) elements. Such an 
insurer may be forced to operate on a single server and 
merely partition between underwriting, database mainte- 
nance and reporting functions. Such an insurer may not 
have adequate firewalls between these elements of their IT 
system, (seen here as item 61). The present invention al- 
lows each insurer to utilize the level of features they are 
most comfortable with and can best use given their sys- 
tem. If the insurer in question has what they believe to be 
adequate internal firewall protection, and wishes to do so, 
they can choose to use a more limited version of the 
present invention software, (item 62). The software level 



of features available never changes but the selections of 
options remains table-driven and under the control of in- 
surer. As an alternative, they can simply send, directly 
from their reporting server, sub-system or node, (item 

63) , entire files of policy initiations and also all suspen- 
sions, terminations and cancellations, to the present in- 
vention's central computer system. There, all data is 
"gleaned", (file field extraction), has a randomly-assigned 
UC added to each combination of policy and object of 
value identification number, (VIN, manufacturer or distrib- 
utor's ID, as previously described, or to two other ele- 
ments as directed by insurer and/or governmental entity), 
and is returned to the present invention's portal where it 
is then sent to the company handling Identification docu- 
mentation production, (if required, and illustrated as item 

64) , to the government system, (typically to a node of the 
present invention resident there) and, along with confir- 
mations, etc., to the insurer involved. The procedure de- 
scribed happens almost instantaneously because deci- 
sions are made by first identifying, (by means of the 
NAIC-assigned five digit insurer identification number), 
the insurer involved and then initiating actions, (field ex- 
tractions) based only on the previously established 



choices of same. Given the very limited level of these re- 
quirements, this requires very little processing and hence, 
no real delay. 

[0119] | n pig. 3C, is seen the sole alternative to the present in- 
vention's insurer-based supply of data to the government 
database. Increasingly, governments are choosing to sim- 
ply utilize a separate server (item 65), inside a govern- 
ment-controlled "DMZ" so as to establish an intranet. This 
has several advantages over the alternative seen in 3A and 
3B, including the ease of implementation, (other than 
linking to APIs, there is almost no implementation re- 
quired), and the additional safety inherent in such a sys- 
tem. Additionally, as big State systems have a poor history 
of availability, this configuration, with its automatic back 
up by the present invention's central database, ensures 
that law enforcement, the courts, and other government 
agencies can always at least get insurance status, (item 
66). 

[0120] pig. 4 represents the present invention in operation at a 
government site (illustrated generally as item 67), rather 
than at an insurer site, however, while terms and elements 
may change slightly, the claimed features of the present 
invention remain identical. Instead of policy initiations, 



this system's intake is insurer files and the UC is assigned 
to either the same combination used by an insurer, (just 
as in Fig. 3), or to at lease two other elements chosen by 
the government involved. The report element of this sys- 
tem, like that of the insurer version in Fig. 3, is composed 
of "notices of terminations, suspensions and cancella- 
tions". In this scenario, note also that there may be ad- 
vantages in direct communication, (at least in regards to 
the UC assigned), between insurer and insurance identifi- 
cation documentation manufacturer, and that is illustrated 
as item 68. 

[0121] pig. 4B, and identified generally as item 69, should be 
viewed in relationship to both Fig. 4A and Fig. 3B. It is 
simply the same as 3B with the previously referenced 
changes discussed in 4A. 

[0122] pig. 5 illustrates access to the present invention's data. 

Item 70 begins the first method mehod, (Module A), which 
involves secure device access. This might be a "smart 
card" and related "smart card" reader, a "chip card", 
(memory only chip-based ID technology), and related 
reader, a bar code element and related device, or any 
other ID and related reader device that provides additional 
security. Item 71 illustrates the decision then made by the 



reader device regarding the legitimacy of the ID card or 
similar device. If the encryption does not match, then the 
ID device is rejected and, as illustrated by item 38 previ- 
ously, the process ends. If it matches, the process contin- 
ues and the reader then adds additional headers, 
(illustrated by item 72), to identify itself to the system, 
and sends that plus the unique identifier, or unique code, 
(the "UC"), to the present invention's interface, (item 73), 
to its central server, (item 74), or to the present inven- 
tion's node at a government site as described previously 
and which contains the exact same data. The result of the 
query, (which will be one of three responses: insurance 
policy on this vehicle is "active", insurance policy is "inac- 
tive", or "there is no record of insurance", will be returned 
immediately to the reader identified as item 70. 
[0123] Module B is identified as item 75 and is simply the use of 
an interactive device that might be a telephone, PDA, 
computer using a simple web interface or similar, having 
connectivity and direct access to the interface, (item 73) 
for the present invention"s database(s). Because the 
present invention maintains no names, addresses, or any 
other details of a personal nature or commercial value, 
and the entry and retrieval is so limited, this is totally safe 



and non-invasive. 
[0124] Module C, which begins with item 76, is almost identical 
to the procedure described previously and illustrated by 
item 75that the user is first asked if the query relates to 
an accident, emergency or theft, (item 77). If the user in- 
dicates a negative response, then the process continues 
exactly as it did in Module B, (item 5). If the user indicates 
a positive response, and an electronic reading device is in 
use, and the ID card of other identification document has 
in memory or symbols, the relevant NAIC code, that con- 
firmation is instantly recorded along with the NAIC code, 
(item 78). This code identifying this insurer is thus already 
included in the data stream and is used as a header for 
access to data and also for records that might be accessed 
and used by insurers and/or governments, (as identified 
by item 80), at a later time. Note that the query continues 
to item 73, representing access to the present invention's 
stored data. If this is a telephone, wireless, internet or 
other type of query, then the NAIC code is obtained by 
reference to the UC as all UCs are matched to specific in- 
surer NAIC codes when assigned as a block for insurer 
use. In either case, if a positive response to the query re- 
garding accident, theft, or other emergency is obtained, 



then the notification of accident or theft report along with 
the UC is transmitted automatically to the insurer in- 
volved. 

[0125] item 79 represents the present invention's automatic for- 
warding of the indication that an accident or theft has oc- 
curred along with the UC involved which identifies the ac- 
tual policy so that the insurer involved may be quickly in- 
formed and enabled to take action to assist the policy- 
holder and perhaps mitigate risk rearding potential losses. 
This additional feature is of very great benefit to insurers 
and policyholders. Likewise, the present invention pro- 
vides APIs to all government entities involved so that they 
may choose to further link their system server to that of 
the present invention in order that an accident report filed 
later by law enforcement automatically sends the UC in- 
volved and a code representing the fact that an accident 
has occurred automatically, to it. This further enables the 
present invention's server to automatically provide it to 
insurer involved. 

[0126] item 80 represents the insurer data system and item 81 
represents the government data system. Note that items 
80 and also illustrate the ability to query the present in- 
vention database and obtain both status, (exactly as de- 



scribed by item 75), and reports based on the limited data 
maintained. 

[0127] pig. 6 begins to detail the third and last section of the il- 
lustrative embodiments, which is actually a more detailed 
description of one element, ("gleaning" or file field extrac- 
tion and related routines), of the art identified in Figures 1 
through 4. 

[0128] The present invention is illustrated with reference to data 
streams, consisting of inbound file initialization and out- 
bound report or "statement" streams common to insur- 
ance and especially to vehicle insurers. Additionally, the 
files accessed may or may not be in "live" files, but in a 
database other than the insurer's "stacks" or central 
database. In many cases, this may be archived data. The 
gleaning process, (file field extraction), operates in that 
case in exactly the same manner. This is applicable to 
both insurer and government systems dealing with insur- 
ance data. No distinction is made herein between an ini- 
tialized (accepted) insurer file, (which could actually be a 
new policy, any addition to a policy, or a "reinstatement"), 
or in the case of a government server, an approved file 
from an insurer that had been submitted for processing. 
To the present invention, these "inbound" data streams or 



files are all exactly the same. Likewise, no distinction is 
made, regardless of where initiated, between a "state- 
ment", "printed report" or "report". To the present inven- 
tion, these "outbound" data streams or files are also all 
exactly the same. Additionally, with few exceptions, both 
groups of data streams, ("inbound" data streams or "out- 
bound" data streams) or "add" files and "report/outbound" 
files are the same. How, when, and where they are pro- 
cessed is decided by others using the present invention's 
features. 

[0129] There are three common methods available for perform- 
ing the tasks regarding file field extraction. All are prior 
art but the of the "UC" and other aspects of the present 
invention make their usage in matters of insurance verifi- 
cation unique. One or more may be used by the present 
invention in a single site. Extraction software based on 
recognition of identifiable characteristics, often called 
Parametric Information Extraction, or "PIE" is well- 
documented in prior art by such patents as 4,965,763 to 
Zamora. Additionally, these tasks can also be accom- 
plished by Print/Report Stream File Field Extraction, using 
knowledge of common print languages, print positions on 
report pages, etc.. The most common method also re- 



mains the simplest: the use of a table-driven software 
routine to indicate exactly where in the data stream or file 
a certain field will be found and what constitutes, in that 
field, a proper population of same, after which, file field 
extraction is handled automatically. 
[0130] FIG. 6 provides a general overview of the manner in which 
a data stream is processed according to the present in- 
vention using Print/Report Stream File Field Extraction, 
and specifically illustrates a production data stream and a 
sample data stream. The production data stream may be 
in the form of an approved file initiation, (often referred to 
as an "add"), or, if dealing with a suspension, termination, 
or cancellation notice, it would be a statement, print or 
report stream, (all of which are identified and handled as 
the same by this present invention). The example used in 
this instance, is of the type that would be sent to a printer 
for printing an "inactive" notice, and this version is very 
typical of the "Print/Report Stream File Field Extraction" 
version. It may come directly from the document-pro- 
cessing computer that generates the print stream in the 
first instance, or it may come from a special report server 
or node, which has been instructed by the computer pro- 
viding the instruction to print this document. In any case, 



such a print/report data stream would generally carry 
printer code for printing a plurality of reports that may 
have a number of different report formats. 
[0131] For example, in insurance operations, the production print 
data stream may contain the requisite coded information 
for a batchof policy account statements to be forwarded 
to policyholders, notification letters for upcoming expira- 
tions, as well as internal financial reports for the insurer's 
use; it may also or instead, contain coded information for 
printing a batch of reports all having the same report for- 
mat. The sample print data stream is a smaller print data 
stream containing representative reports for use in devis- 
ing data extraction templates as explained below. In the 
case of new "adds", (approved policies, policy additions, 
or accepted files if a government site is involved), the 
procedure is exactly the same, and only the terms, "add" 
or "initiation" instead of "print" or "report" actually 
change. 

[0132] The data stream is simply, (and always), a binary data 
stream of the type sent to either initialize a file in a 
database, (but is read prior to passing a firewall and doing 
so), or to a printer to produce printed statements and re- 
ports. The present invention may read the same in a 



database, but they have first been passed to same by the 
means described above. The binary data stream encom- 
passes the informational content to be reported as well as 
formatting codes and file and/or printer control codes. 
The present invention only seeks data that is very limited, 
which never includes bit-mapped image data or anything 
other than very small file elements. The data stream in- 
volved, may, however, contain a large volume of addi- 
tional data unnecessary to the present invention and 
which must be ignored. The term, "report data stream", is 
used broadly herein to refer to a sequence of coded infor- 
mation of the type to be sent either to a database as an 
approved file or to a printer to issue a notification regard- 
ing suspensions, terminations, or cancellations. The term 
may include an entire sequence to be sent in one or more 
jobs, and it may include only a portion of a sequence to 
be sent. 

[0133] insurers use underwriting systems and central databases 
of many different types, but they all share commonality in 
regards to the use of profilers, and "price and place" ele- 
ments. Likewise, governments accepting insurer-supplied 
data operate in an almost identical, (but slightly simpler), 
manner by first determining that certain fields are present 



and key elements are provided, prior to processing. The 
present invention's use of XML and similar "agnostic" soft- 
ware ensures that the differences involved are of little or 
no consequence, as it simply first verifies that the re- 
quired fields in the data stream are present and properly 
populated, then handles field extraction. The assignment 
of a Unique Code to two elements previously determined 
by the system user, spools the results, and later pub- 
lishes, (transmits) same. 

[° 134 ] Insurers are required by legislation and/or regulation in 
many States, Provinces and other jurisdictions to provide 
notifications to both policyholders and government enti- 
ties responsible for monitoring compliance with manda- 
tory insurance coverage. Over time, insurers have increas- 
ingly determined that the benefits to both their profitabil- 
ity and to their policyholders is enhanced by providing 
these notices and typically provide such notifications to 
governments and policyholders even in jurisdictions 
where they are not required to do so. The absence of uni- 
formity in required reports has however, created severe 
logistical and resource concerns for insurers. The present 
invention entirely resolves those issues and concerns. 

[0135] while all requirements can be easily handled by the afore- 



mentioned art, it is important to remember that there are 
three different methodavailable from prior art to handle 
these needs. Figure 6, while exemplary to the present in- 
vention generally, is somewhat more specific to the use of 
extractions from print/repot data streams. Print/report 
data streams are often written in one of several estab- 
lished languages, sometimes referred to as page descrip- 
tion languages. Consequently, the previously described 
ability of the present invention's XML-based features in 
Underwriting or Government data intake, would not be 
used if extraction from print/report data stream using a 
page description language was used instead, not because 
it would fail in that task, but simply because only one of 
the three demonstrated methods are required, (although 
more than one method might be used by a single insurer 
elsewhere as they often have multiple sites). Examples of 
such types of print/report data streams include ASCII, 
several generations of the PCL language from Hewlett- 
Packard, the PostScript language from Adobe Systems, 
Inc., and the Advanced Function Presentation or AFP lan- 
guage from IBM. A large enterprise-wide computer system 
will generally include numerous printers sometimes re- 
quiring report/print data streams of different types, and 



the data stream originating at any given time in any given 
department of the enterprise may thus be one of several 
different types. While not the preferred embodiment, this 
method might be determined as more advantageous for 
an insurer or government, and is thus noted as the 
present invention remains unaffected by such methods. 
[0136] Each report in an individual report data stream will have 
associated with it a report type, which indicates, for ex- 
ample, whether the report is a billing notice, an offer of 
additional services, a thirty day warning prior to termina- 
tion, special notices regarding types of insurance, (PIP, 
SR-22, SR-26, etc.), or n official suspension, termination, 
or cancellation; it could also be an internal activity report 
or some other category of report. Each report will include 
a number of fields for presenting information, such as 
policy number, date, VIN number, zip code of the policy- 
holder, and much more. In addition, each report type may 
be revised from time to time to change the layout of the 
report or to add further content-bearing fields. Thus, each 
report type will have associated with it one or more ver- 
sions as such modifications to the report format take 
place. The format of a printed report, (that is, the format 
of a report in the report data stream), will be determined 



once the report type and version are specified. 

[0137] | n t he past, to retrieve selected data, such as the policy 
numbers for all reports in the report data stream, it has 
generally been necessary to hard-code the input software 
with the location of the each policy number so that the in- 
put software will know where in the report data stream to 
find the policy number information. With the methods of 
the present invention, selected data may be retrieved from 
a data stream, even after the formats are revised and new 
data fields are added, without revising any computer soft- 
ware code. As described below, an operator having no 
technical computer expertise or knowledge of program- 
ming may update the system to account for modified or 
entirely new file or report formats. This is achieved in the 
case of the print/report data stream extraction method, 
part by providing an extraction database (item 82), con- 
taining file or report format information for each of the 
file or report formats in use. The extraction database may 
be maintained and manipulated by a business user 
through a graphical user interface or menu system at a 
display terminal. 

[0138] while this documents the present invention's ability to ac- 
commodate such needs, it should be remembered that a 



far more subset of these features is actually provided to 
an end user, (governmental entity or insurer), along with a 
GUI. This accomplishes two things: it ensures that 
changes will be accomplished in minutes, rather than 
hours by an even more unskilled operator than that en- 
abled by the full features of the present invention, and it 
further ensures that the insurer and/or government entity 
involved maintains control over what can be changed, and 
how those changes can occur. In effect, an additional layer 
of control and "direction" is added. 
[0139] a description is now given of the manner in which a pro- 
duction file or report data stream is analyzed and pro- 
cessed. As indicated at block/item 83, the production file 
or report data steam is first analyzed to determine the 
data stream type, and in the case of a report or print data 
stream, it is assumed that this might involve the type of 
printer language used, thus this instance is fully de- 
scribed. 

[0140] Continuing, and now assuming, (to assure a "most diffi- 
cult case" scenario), that the present invention is using 
page description language, it must then be analyzed at 
the block identified as item 84 to determine the report 
type and the report version of the first report. First, the 



beginning of a first report in the report data stream is 
found. Methods for locating the beginning of reports or 
other file in a report, (in this case, also the "print data 
stream"), are well known and are prior art. Typically, the 
data stream will contain a code indicating the beginning 
of each report, or alternatively an algorithm may be ap- 
plied to the report data stream to determine report begin- 
nings. 

[° 141 ] Each report will typically be preceded by a file in the form 
of a header or a sequence of coded fields including data 
inthe report type, which data may be found at a charac- 
teristic location in the header or sequence and so may be 
determined easily and automatically. 

[0142] Thereport version can also be determined either directly 
or indirectly from the report data stream. The report ver- 
sion may be directly encoded in the report header or in 
coded fields and may be retrieved directly along with the 
report type. Alternatively, the report may include other in- 
dicia from which the report version may be derived. For 
example, a report will typically include a standard State 
code, (such as CA, GA, or IL), or alternatively a code rep- 
resenting a specific Province or other jurisdiction. Where 
only one version of the report format is operative at a 



time, that is, different versions of the report format are 
not in use during the State reporting range, the report 
date or time may be used to effectively identify the report 
version. In this case, the report format information stored 
in the extraction database for this report type will asso- 
ciate each version with its operative date or date and time 
range. The print data stream is analyzed for the report 
date or time, which is compared with the date or date and 
time ranges included in the report format information for 
the given report type to find the report version. The man- 
ner of carrying out such comparisons is routine and need 
not be disclosed in detail here. 
[0143] The addition of time frames instead of just dates may be 
valuable since that information may be utilized to further 
evaluate and choose files. It is generally assumed that re- 
porting will be at least daily, but may be far more fre- 
quent, (in fact, some large insurers will doubtless use an 
"open pipe" for continuous and so all files for a given 
date, will normally (at the very least) be transmitted that 
same day, or in the early hours of the following day. It is 
common practice for insurers to bind coverage automati- 
cally for at least a twenty-four hour period which, with at 
least daily reporting, means that the present invention de- 



livers accurate status information at all times. Likewise, if 
reporting may not be daily, but the binders used still 
cover the period, the system's information remains cur- 
rent and totally accurate in any case. 

[0144] As indicated above, the extraction database (item 82), 

contains report format information for each of the report 
formats that can arise in the report data stream. The re- 
port format information for a given report format includes 
a report type, a report version, and at least two ex- 
tractable fields. By extractable field is meant a content- 
bearing field that is present in the report format, the con- 
tent of which a user may desire to extract from the report 
data stream. The extractable fields in the database are the 
fields of data that the present invention makes available 
to be extracted from the report data stream. In general, a 
plurality of extractable fields will be defined for each re- 
port format. These features are the same for all initiation, 
("adds") files as well. 

[0145] Each extractable field is provided, (reported or printed), at 
a prescribed position in the corresponding report format, 
that is, in the corresponding version of a given report 
type. The field position may be a fixed position on the 
viewed or printed page, (for example, a date field that is 



centered a set distance fom the te top of the page). In this 
case XY coordinates on the report page may specify the 
position for example. Alternatively, the field position may 
be specified as a relative position, for example, notifica- 
tion text that appears at prescribed coordinates with re- 
spect to the last entry in a column with a variable number 
of transactions. The report format information in the ex- 
traction database associates a field position with each ex- 
tractable field indicating the position at which the ex- 
tractable field is reported and/or printed in the corre- 
sponding report format. Again, these features are com- 
mon with "adds" in Underwriting or in Government intake 
systems in which only the terms change, ("report" changes 
to "add" or "initiation", for example). 
[0146] Once the report type in the report data stream is known, 
the report format information can be retrieved from the 
extraction database and the version determined. Each ex- 
tractable field identified in the report format information 
for the given report type and version may then be sought 
in the report data stream. This is achieved by searching 
the report data stream for report/printer code for printing 
or reporting a data field at the position associated with 
the desired extractable field in the retrieved report format 



information. As an example of a field printed at a fixed 
location, consider a date field beginning at given XY coor- 
dinates in the printed report, then the date field may be 
sought in the data stream by searching for appropriate 
printer code that causes a field to be printed at the pre- 
scribed XY coordinates. The content of that field, that is, 
the information to be printed beginning at the prescribed 
XY coordinates, is then extracted (see block/item 85), and 
the system proceeds to search for the next desired ex- 
tractable field. 

[° 147 ] If, at some time the report format is revised so that a spe- 
cific field appears at a different location on the page 
specified by new XY coordinates or perhaps now specified 
as a relative position, then it is only necessary to revise 
the report/print position entry for this field in the extrac- 
tion database for the given report type and version. Simi- 
larly, if the format is revised to include new data fields, or 
if it is desired to search for and extract data fields that 
had not previously been designated, it is only necessary to 
add the fields with their associated print/report positions 
to the extraction database. This invention provides a con- 
venient method for accomplishing this. 

[0148] jo define or update the extraction database, a sample 



data stream is presented to an extraction setup module 
(item 86). The sample print/report data stream comprises 
a data stream for a sample report or for several sample 
reports of different formats if more than one report for- 
mat is to be added or updated in one session. The extrac- 
tion setup module (item 86), searches the sample print/ 
report data stream for all fields in the sample report (or in 
the first sample report if more than one report is included) 
in the same way as above by looking for print commands 
in the print data stream. Such fields constitute candidate 
fields for possible inclusion in the extraction database. 
The candidate fields are presented on a display monitor 
through a graphical user interface or through a menu sys- 
tem. 

[0149] The user then selects the fields to be included in the ex- 
traction database. Means by which a user can enter a se- 
lection are well known to designers of user interfaces for 
display terminals and need not be described in detail 
here. The user can also be given an opportunity to name 
the selected extractable fields. The selected field or fields 
are then stored together with their associated characteris- 
tic print positions (which are known from the sample print 
data stream) as extractable fields associated with the 



sample report format. These functions are currently han- 
dled by the supplier of the present invention, which in 
turn supplies the GUI to end users of present invention as 
their means to make choices and, through these choices, 
effect the required or desired modifications. 

[0150] a description is now given of the manner in which the in- 
formation in a report is organized for use in the present 
data extraction system. The information in a report of any 
given report type is organized according to a hierarchy of 
sections and groups. Each report type can have multiple 
sections. Each section can have multiple groups, and each 
group can have multiple subgroups. A group may be re- 
peatable, meaning that the same group structure is re- 
peated sequentially in the document as many times as 
needed to display the relevant data. The data displayed in 
a group appears in fields, and a group may have any 
number of fields. A section is a logical object that pro- 
vides for the presentation of data in multiple columns. A 
section represents a list of physical pages having the 
same columnar layout, that is, one-column pages, two- 
column pages, etc. 

[0151] The signature will generally involve a character string ap- 
pearing in a group, although it may not be an extractable 



field. The signature takes the form of a prescribed alpha- 
betic, alphanumeric or other character string or a pattern 
of characters. The signature may also include coordinate 
locations, (absolute or relative), for the start of the signa- 
ture or may be defined by a combination of coordinates, 
character strings, pattern matching, or even font identifi- 
cation. In general, the definition of signatures is intended 
to be flexible and thus may include other distinguishing 
characteristics such as font type. 
[0152] within each group there are at least one and typically a 
number of extractable fields. These fields are defined by 
their location relative to the group signature. Thus, to find 
a desired extractable field in a data stream it is only nec- 
essary to know the group to which the field belongs, to 
find the group signature in the data stream, and to then 
go to the desired field's location relative to the group sig- 
nature. 

[0153] jo extract a selected field from a print/report data 

stream, the following preparatory steps are required: First, 
the print/report data stream is parsed to find the bound- 
aries of all the reports in the data stream. This is a 
straightforward task in the illustrated embodiment be- 
cause each report begins with a "Begin Document" tag and 



ends with an "End Document" tag. Each report is then 
parsed to find each page of every report and each ex- 
tractable field on each page. In the illustrated embodi- 
ment "Begin Page" delineates the pages of a report and 
End Page denotes the end of each. The fields are found by 
their coordinate locations relative to the group signature. 
Methods for parsing AFP data streams are known in the 
art and AFP parsing software is commercially available. 

[0154] a table is then compiled of all the extractable fields, with 
each entry in the table having the format (X, Y, font, con- 
tent), where X, Yare the coordinates of a standard refer- 
ence point for the field, for example, the lower left corner 
of the field. "Font" refers to the font in which the text data 
appears, and "content" refers to the extractable content of 
the field. That is to say, an extractable field may include 
standard headings or other characters. 

[0155] The extractable fields on each page are then organized in 
two ways by means of two hash tables. These are referred 
to as the X-hash table and the Y- hash table, and they 
sort the extractable fields on a page by their X and Y co- 
ordinates, respectively. By pre-sorting the text fields in 
this way, this technique limits the scope of searching and 
improves the performance of the information extraction 



process. 

[0156] jo successfully extract selected data from a print/report 
data stream according to the present invention, an extrac- 
tion database is needed that indicates the extractable 
fields available for each report type in the print/report 
data stream and specifies expressly or implicitly the print/ 
report positions of those fields The method of the present 
invention may be utilized, and advantages of the invention 
may be realized however, no matter how the extraction 
database is provided. 

[0157] The extraction database is generated from a sample 

print/report data stream that contains a master report of 
a given type. The print/repdata stream is examined to de- 
termine the layout of the hierarchical structure of the re- 
port in sections and groups and to identify all possible 
extractable fields in the report. The hierarchical structure 
is recorded in an internal form that is figuratively referred 
to as a template for the report type and is used for defin- 
ing filters by which a non-technical user may select ex- 
tractable fields to be parsed from a print/report data 
stream. All the needed information on the hierarchical 
structure of the report type is included in the report tem- 
plate, which is stored in the extraction database for future 



use. 

[0158] initially, a technical user prepares a template for each ver- 
sion of each report type that might be required. The tech- 
nical user examines a sample print/report data stream for 
each report type. This is conveniently performed graphi- 
cally by displaying the sample report type on a display 
monitor. The user then identifies the areas of the report 
that are desired to be sections, groups and fields. For 
each identified group and section the user identifies an 
associated signature. Successive signatures define the 
group and section boundaries. When the user indicates 
that a group signature is in "fixed position", the system 
automatically stores the fixed location in the appropriate 
attributes of the group object table. 

[0159] if the group signature is floating, i.e., the location of the 
group can vary depending on the content of the group, 
then the user specifies the characteristics of the signature, 
which will include one coordinate (X or Y), and perhaps 
the match string or pattern, and another feature, like the 
font. The specified signature characteristics are automati- 
cally entered into the appropriate attributes of the group 
object definition table. If a group is defined as floating, 
then all its subgroups and fields are automatically defined 



to be floating and signatures will have to be defined for all 
such subgroups and fields. During template definition the 
user identifies all the fields that are to be extractable. The 
location of each of these fields is recorded relative to the 
signature of the group to which the field belongs. These 
fields will serve as candidate fields that a non-technical 
user may later choose to select for extraction. The sample 
report used to define the template is saved with the tem- 
plate. 

[0160] Once a template for a report type and version has been 

defined, it may be used for extraction of data from a pro- 
duction print/report data stream. A non-technical user 
may select data for extraction by defining a filter based on 
the template, but in all cases these pre-determined tem- 
plate choices are restricted to those authorized by the 
governmental entity and/or insurer involved. The user se- 
lects a report type and version and the system opens a 
copy of the appropriate, approved template along with the 
sample report from which the template was generated. 
The approved extractable fields, groups and sections are 
presented to the user as candidate fields or areas to be 
extracted, and the user then selects the areas or individ- 
ual fields available. The appropriate bits are then auto- 



matically set in the corresponding attribute for the object. 
Methods by which a user may select areas or fields on a 
graphic display are routine in the art and not discussed in 
any detail here. 

[0161] The user will also have the option of specifying an output 
format for the extracted data. These output formats will 
be limited by template choices and must conform to pre- 
vious decisions which are governmental and/or set by the 
insurer involved. The template corresponding to the user's 
selections is then saved in he extraction database as a fil- 
ter for use in the extraction process. The print data/report 
stream is then examined and parsed using the methods 
described above to find the fields indicated in the filter, 
and prepared for distribution, file maintenance, etc. as 
described earlier. 

[0162] pig. 7 represents a typical code sheet page from an insur- 
ance policy initiation. As discussed previously, the most 
common method of "gleaning" files, (file field extraction), 
is also the simplest: the use of a table-driven software 
routine to indicate exactly where in the data stream or file 
a certain field will be found and what constitutes, in that 
field, a proper population of same, after which, file field 
extraction is handled automatically. Fig. 7 demonstrates a 



very typical example of how data streams are documented 
in the insurance industry. On this page, it can be noted 
that in block 313, an address begins and it is possible 
that this "address block" ends with block 377. On the 
other hand, it may be that, given that the "zip code" is 
seen in blocks 356-360, that block 360 is the last ele- 
ment, (very last available block), of the "address block" or 
"address section". 
[0163] pig. 7 appears to be a representative code sheet from a 

vehicle insurance policy, but that may not be the case. It is 
common to list assets on other applications for various 
forms of insurance, including a vehicle or perhaps numer- 
ous vehicles. 

[0164] a s discussed previously, these matters and concerns are 
very easily handled. A GUI is utilized to access a table- 
driven "set-up" routine is a common interface tool well 
documented in prior art. Using the example of a vehicle 
policy, (but remembering that this could be any type of 
policy), the user is asked what constitutes a "vehicle pol- 
icy". This is to ensure that the system properly recognizes 
the type sought since there are numerous types of polices 
and a particular company may have "mixed traffic", 
(polices of various types "in-bound" and "out-bound"). 



The system's decisions are assisted by that information 
but other identifiers are also used to determine if a sec- 
tion contains, for example, a VIN, ("Vehicle Identification 
Number"). If this is an example of the system looking for a 
vehicle policy and therefore, first looking for a VIN, it has 
been programmed to recognize the formats containing 
seventeen characters, (or nine characters if a vehicle pro- 
duced prior to 1980), and thus, knows that it is dealing 
with an actual vehicle. These software requirements are 
prior art and readily available from commercial sources. 
The present invention has indeed, used this element, and 
obtained from others, for years. 
[0165] The system must know with certainty, if it uses the most 
common method described above, what actual locations 
in a data/report stream that the VIN, approval code, and 
other required elements will utilize. The system must also 
be instructed what actually constitutes an approval code, 
etc.. If block 1037 is normally used for an approval code, 
but may in certain circumstances, be used for something 
else regarding a vehicle policy, (assuming once again that 
a vehicle policy is discussed), then the actual number(s), 
letter(s) or other symbols that represent an approval code, 
must be known and recorded, along with the block or 



blocks representing location of same. 
[0166] The descriptions and drawings in this document disclose 
illustrative embodiments of the invention. Given the bene- 
fit of these disclosures, those skilled in the art will appre- 
ciate that various modifications, alternate constructions, 
and equivalents may also be employed to achieve the ad- 
vantages of the invention. 



